1. Field of the Invention
The present invention relates to computer security systems for ensuring secure interaction between various software components.
2. Description of the Related Art
EP1631032 describes a method and system for control of computer resources based on various parameters and access policies. This reference describes how parameters for accessing a certain resource (such as a software component) are formed.
U.S. Pat. No. 6,978,381 describes a system and method for processing of secure data. In this reference, a list that includes various access levels, profile lists and user lists is formed. The access to the data is then implemented based on the lists.
U.S. Patent Publication No. 2005/0251508 describes a system and method for file access that uses a list of file parameters. The access to the files is implemented is based on the parameters list.
U.S. Patent Publication No. 2003/0055991 describes a system and method for accessing an object. This reference describes how the data regarding the object, the access commands, the data regarding the actions, etc. are formed. The mechanism for determining whether access to the object should be permitted utilizes a first set of commands for access control, where the object has specified parameters that correspond to the object context. A second set of commands controls access such that the parameters of the access are hierarchically broader than the parameters of the context.
U.S. Patent Publication No. 2005/0262362 describes access control to an object based on parameters relating to its name, parameters relating to resources, and parameters relating to the object itself.
One of the difficulties in a modern approach of software development and in ensuring security for interaction between software components is the fact that the component itself has to be designed with security in mind. In other words, security aspects must be built into the component itself, and, generally, cannot easily be added or changed later. This adds a considerable burden on the developer, and also increases the likelihood of bugs and errors in the software, which virus writers and hackers can exploit down the line. On the other hand security requirements for distribution, deployment, selling, licensing, configuration, administration, using, etc. are highly dependent on a particular use case. These types of different requirements are very difficult to implement and even to enumerate in advance, which makes it virtually impossible for software component users to enforce their own security strategy, if it does not correspondent to the security model implemented in the software component.
An example of such a built-in security system can be found, for example, in modern file systems, such as the NTFS file system, the mail services, phone services, such as those available in Microsoft Windows™, and so forth. For example, in the case of the NTFS file system, the Microsoft Windows™ operating system checks whether whichever software components is trying to access a file actually has permission to access that file. In this case, the security is built into the file system and the APIs that support it.
On the other hand, earlier systems, such as FAT32 and FAT16, do not have a built in security, and adding a level of security to these file systems is virtually impossible. Even those conventional systems that have security built into them do not have the option of changing the parameters of the security system based on the life stage of the particular software component.
Accordingly, there is a need in the art for a system and method that addresses secure interaction between software entities, in a manner that removes much of the burden relating to the security of the interaction from the developer of the software component itself.